none
AD Attribute msRadius-Framed-IPv6-Address / msRADIUS-FramedInterfaceId falsche Länge RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich probiere in einem Standard Schema 2016 AD diese Attribute zu setzen (Active Directory Users and Computers > User Object > Dial-in > Static IP Addresses > Assign a static IPv6 address > Prefix and Interface Id)

    Dabei ist mir aufgefallen, dass die max. erlaubte Länge nicht so wirklich dem RFC der entsprechenden RADIUS Attribute entspricht.

    msRADIUS-FramedIpv6Prefix: max. 16 characters (Beschrieben im Schema 'rangeUpper')
    msRADIUS-FramedInterfaceId: max. 8 characters (Beschrieben im Schema 'rangeUpper')

    ===================================================================

    Der RFC sagt:

    Framed-IPv6-Prefix [97]: https://tools.ietf.org/html/rfc3162
    Length: 4 - 20 Byte (2 Bytes len field; 2 Bytes prefix length; 16 Bytes for the IPv6 prefix)
    Description: Prefix first, followed by the address
    Example: 2001:db8:85a3::8a2e:370:7334/128
    ==> Value in Framed-IPv6-Prefix field: 00:80:20:01:0d:b8:85:a3:00:00:00:00:8a:2e:03:70:73:34 (18 Bytes)

    Framed-Interface-Id [96]: https://tools.ietf.org/html/rfc3162
    Length: 10 Byte (2 Bytes len field; 8 Bytes for the Interface-Id)
    Description: Host part of an IPv6 address
    Example:
    0123:4567:89AB:CDEF
    ==> Value in Framed-Interface-Id 01:23:45:67:89:ab:cd:ef (8 Bytes)

    Die Frage ist jetzt wie es gedacht ist dieses Feld im AD zu pflegen.

    Wenn man das Feld für IPv4 anschaut, gibt man da eine IPv4 Adresse als "String" ein (also gut lesbar).

    Wie ist das für IPv6 gedacht? Wenn man einen IPv6 Prefix "lesbar" dort eintragen soll, reicht die Feldlänge nicht (auch Doppelpunkte, Slashes etc. zählen).

    Weiß jemand ob das "works as designed" ist? Falls ja, wie ist es gedacht dieses Feld zu benutzen?

    Freitag, 19. Juli 2019 06:57
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    mein Verständnis ist, dass die beiden Attribute nicht ganz RFC-konform aufgesetzt sind, sondern den folgenden Prinzipien folgen:

    • msRADIUS-FramedIPv6Prefix berücksichtigt kein CIDR, sondern geht per ursprünglicher Definition davon aus, dass das Präfix (Route + Subnetz) exakt 64 Bit lang ist. Damit kann entweder mit allen Nullen oder mit der gekürzten Schreibweise mit Doppelpunkten das Präfix in Hex reingeschrieben werden, 16 Zeichen werden dafür immer ausreichen.
    • msRADIUS-FramedInterfaceID hingegen ist eine Bitfolge, als String dargestell. Da im obigen Modell auch die Interface-ID exakt 64 Bit lang ist (evtl. mit führenden Nullen halt), sind 8 Byte dafür genau ausreichend. Da der String im AD jedoch als "IA5 Printable" definiert ist, können nicht alle möglichen Bit-Kombinationen zum Einsatz kommen - doch selbst wenn man sich auf Großbuchstaben, kleinbuchstaben und Ziffern einigt, ergibt das 62^8 = 218.340.105.584.896 Kombinationen, sollte also selbst dann ausreichen, wenn das jeweilige AD die gesamte Erdbevölkerung abbildet. Aber dadurch kann man da z.B. den SAMAccountName reinschreiben, wenn er kurz genug gehalten ist. Macht die spätere Zuordnung zum User einfacher :-)

    Übrigens, Deine Wahrnehmung "IPv4 wird als String dargestellt" ist nicht ganz zutreffend. In der GUI wird die Adresse eben NICHT als String, sondern als "valide IPv4-Adresse" dargestellt, inklusive Aufteilung durch Punkte und Prüfung der Werte für die einzelnen Teile. Das Attribut im AD hingegen ist eine lange ganze Zahl, und zwar leider genau nicht so berechnet, wie die .NET-Klasse [IPAddress] das intern tut, sondern in der umgekehrten Reihenfolge. Das ist wichtig zu wissen, wenn man anfängt das Zeug zu automatisieren.

    Evgenij Smirnov

    http://evgenij.smirnov.de


    Montag, 22. Juli 2019 08:23
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    IPv6 ist grundsätzlich nicht dafür gedacht, von Menschen gelesen und geschrieben zu werden. Drum scheitern alle IPv6-Migrationen, die unter der Prämisse angefangen werden "wir machen wie bisher, nur sind die Adressen länger".

    Und von fixen Adressen, außer für wenige ausgewählte Systeme wie Router und DNS-Server, hält man bei IPv6 sehr wenig. Aber wenn es sein muss: PowerShell, da kannst Du alles in Bytes und zurück konvertieren. Oder die IPAddress-Klasse verwenden, da gibt es gleich die Methode GetAddressBytes

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 19. Juli 2019 22:13
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo und Danke für die Antwort,

    verstehe die Antwort leider technisch nicht so ganz.

    Natürlich sind bei IPv6 auch fixe IP Adressen vorgesehen. Natürlich gibt es auch die Möglichkeit SLAAC, DHCPv6 (stateful) zu machen... aber statische Adressen sind "by design" auch vorgesehen. Gerade wenn es um Firewallfreischaltungen geht, macht das ggf. schon Sinn. Natürlich gibt es für alle Dinge auch mehrere technische Möglichkeiten (Identity Based Firewalls, keine Firewalls, keine Server :)

    Unabhängig davon und ob man der Meinung ist, dass IPv6 Adressen by design nicht lesbar sein müssen (so ein schmarrn - sorry), sind die beiden Felder auch in reiner Byte Notation NICHT lang genug und entsprechen auch nicht den Spezifikationen des RFC.

    Siehe oben:

    Framed-IPv6-Prefix [97]: https://tools.ietf.org/html/rfc3162
    Length: 4 - 20 Byte (2 Bytes len field; 2 Bytes prefix length; 16 Bytes for the IPv6 prefix)

    ==> Sprich man brauch mindestens 18 Byte in Summe

    Das Feld msRADIUS-FramedIpv6Prefix bietet max. 16 characters.

    Egal wie man das jetzt hin und her konvertiert, wird das nicht ganz reichen :)

    Vielleicht habe ich aber auch einen krassen Denkfehler - dann wäre es total gut, wenn man mich da technisch aufschlauen könnte.

    Samstag, 20. Juli 2019 09:05
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    mein Verständnis ist, dass die beiden Attribute nicht ganz RFC-konform aufgesetzt sind, sondern den folgenden Prinzipien folgen:

    • msRADIUS-FramedIPv6Prefix berücksichtigt kein CIDR, sondern geht per ursprünglicher Definition davon aus, dass das Präfix (Route + Subnetz) exakt 64 Bit lang ist. Damit kann entweder mit allen Nullen oder mit der gekürzten Schreibweise mit Doppelpunkten das Präfix in Hex reingeschrieben werden, 16 Zeichen werden dafür immer ausreichen.
    • msRADIUS-FramedInterfaceID hingegen ist eine Bitfolge, als String dargestell. Da im obigen Modell auch die Interface-ID exakt 64 Bit lang ist (evtl. mit führenden Nullen halt), sind 8 Byte dafür genau ausreichend. Da der String im AD jedoch als "IA5 Printable" definiert ist, können nicht alle möglichen Bit-Kombinationen zum Einsatz kommen - doch selbst wenn man sich auf Großbuchstaben, kleinbuchstaben und Ziffern einigt, ergibt das 62^8 = 218.340.105.584.896 Kombinationen, sollte also selbst dann ausreichen, wenn das jeweilige AD die gesamte Erdbevölkerung abbildet. Aber dadurch kann man da z.B. den SAMAccountName reinschreiben, wenn er kurz genug gehalten ist. Macht die spätere Zuordnung zum User einfacher :-)

    Übrigens, Deine Wahrnehmung "IPv4 wird als String dargestellt" ist nicht ganz zutreffend. In der GUI wird die Adresse eben NICHT als String, sondern als "valide IPv4-Adresse" dargestellt, inklusive Aufteilung durch Punkte und Prüfung der Werte für die einzelnen Teile. Das Attribut im AD hingegen ist eine lange ganze Zahl, und zwar leider genau nicht so berechnet, wie die .NET-Klasse [IPAddress] das intern tut, sondern in der umgekehrten Reihenfolge. Das ist wichtig zu wissen, wenn man anfängt das Zeug zu automatisieren.

    Evgenij Smirnov

    http://evgenij.smirnov.de


    Montag, 22. Juli 2019 08:23
    |